Systems and methods for managing multi-tenant callback services

ABSTRACT

Systems and methods for managing multi-tenant callback services may be provided via a multi-tenant services integration platform. Several multi-tenant software as a service applications may be offered as a hosted software solution via the multi-tenant services integration platform. Various applications may deploy and support a shared tenant and shared services environment where there can be many different customers (companies and users) running in their own virtual partition from a single application instance. The applications may be multi-tenant aware and integrated into an administration portal which integrates several shared tenant services. The tenant model may allow for customized application configurations to be run from a single application instance. Further, improved methods for providing callback management, calculating estimated wait times, and providing for callback initiation may be integrated in such multi-tenant services.

CROSS-REFERENCE

This application claims the benefit of U.S. Provisional Application No.61/490,035, filed May 25, 2011, which application is incorporated hereinby reference in its entirety.

BACKGROUND

Call or contact centers often use an automatic call distributor (ACD),which is a device or system that distributes incoming calls based onpredetermined criteria to contact center agents or resources. ACDsystems are utilized in situations where a large volume of incomingphone calls are received from callers who have no need to speak with aspecific person but who require assistance from any of multiple persons(e.g., customer service agents or representatives) offered to the callerat the earliest opportunity. Several automated call distribution systemshave developed methods of scheduling callback appointments for incomingcalls which cannot be serviced efficiently at the time the call isreceived because no representatives are available and the caller choosesnot to wait. The scheduled callback mechanism allows an outbound call toa caller who had placed an earlier incoming call to provide immediateassistance to the callback recipient (the caller) without having to waiton hold for an extended period of time. This is often an option that isgood for the caller and good for the company being called that wants toprovide a better experience for its customers.

Automated contact centers generally require a system of hardware forterminals and switches, phonelines, and software for the routingstrategy that determines where best to send the caller. The routingstrategy may match callers up with call agents, using a number ofvariables. When a caller is offered a callback at a specific time, partof this calculation may include an estimated wait time calculation whichis determined based on many variables. In callback systems, it is oftena goal to maximize efficiency of resources (which may include the use ofhardware, phonelines, and software, as well as the time and availabilityof agents). Some systems have shared telephony and call center resourcesto serve multiple tenants (or multiple clients, companies, businessunits, etc.). For example, two or more separate and distinct companiesmay share telephony and contact center resources in a multi-tenantenvironment connecting customer service representatives to theircustomer bases. There is, however, a need to improve the efficiency ofcallback services, including by utilizing shared resources and multipletenant environments so that callback services can be used by manydifferent companies at the same time.

SUMMARY

The invention provides systems and methods for managing multi-tenantcallback services. Various aspects of the invention described herein maybe applied to any of the particular applications set forth below. Theinvention may be applied as a standalone multi-tenant callback servicesmanagement system or as a component of an integrated software solutionmulti-tenant contact center services. The invention can be optionallyintegrated into existing business and callback center processesseamlessly. It shall be understood that different aspects of theinvention can be appreciated individually, collectively or incombination with each other.

In one aspect of the invention, a system for managing multi-tenantcallback services for call centers comprises a plurality of tenants,wherein each tenant provides one or more sets of configuration data; aplurality of call center applications from one or more vendors forassisting a plurality of call center agents; and a queue callbackapplication among the plurality of call center applications for managingcallbacks to connect callers to call center agents over a publicswitched telephone network, wherein each set of configuration data iscustomized for a tenant and associated with one or more of the pluralityof call center applications, wherein the plurality of call centerapplications can support multiple tenants, utilizing one sharedinstallation of the one or more applications, and wherein each tenanthas a virtual partition on which instances of the shared installation ofthe one or more applications is run.

A method for managing multi-tenant callback services for call centersmay be provided in accordance with another aspect of the invention. Themethod may comprise customizing at least one set of configuration datafor an individual tenant of a plurality of tenants, wherein each tenantprovides one or more sets of configuration data; associating the atleast one set of configuration data with one or more call centerapplication from a plurality of call center applications, wherein theplurality of call center applications are provided from one or morevendors for assisting a plurality of call center agents; and managingcallbacks, via a queue callback application among the plurality of callcenter applications, to connect callers to call center agents over apublic switched telephone network, wherein the plurality of call centerapplications can support multiple tenants, utilizing one sharedinstallation of the plurality of call center applications, and whereineach tenant has a virtual partition on which instances of the sharedinstallation of the one or more applications is run.

Other goals and advantages of the invention will be further appreciatedand understood when considered in conjunction with the followingdescription and accompanying drawings. While the following descriptionmay contain specific details describing particular embodiments of theinvention, this should not be construed as limitations to the scope ofthe invention but rather as an exemplification of preferableembodiments. For each aspect of the invention, many variations arepossible as suggested herein that are known to those of ordinary skillin the art. A variety of changes and modifications can be made withinthe scope of the invention without departing from the spirit thereof.

INCORPORATION BY REFERENCE

All publications, patents, and patent applications mentioned in thisspecification are herein incorporated by reference to the same extent asif each individual publication, patent, or patent application wasspecifically and individually indicated to be incorporated by reference.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features of the invention are set forth with particularity inthe appended claims. A better understanding of the features andadvantages of the present invention will be obtained by reference to thefollowing detailed description that sets forth illustrative embodiments,in which the principles of the invention are utilized, and theaccompanying drawings of which:

FIG. 1 illustrates an overall architecture of a multi-tenant servicesintegration platform, in accordance with embodiments of the invention.

FIG. 2 illustrates an example of how multi-tenancy can be accomplishedvia various abstraction layers, in accordance with embodiments of theinvention.

FIG. 3 illustrates and example of the hierarchy for configuration datafor each application within the application layer, in accordance withembodiments of the invention.

FIG. 4 illustrates how configuration data for each application may beimplemented by various tenants and among various agents, in accordancewith embodiments of the invention.

FIG. 5 illustrates an example of an architecture of a multi-tenant queuecallback manager application, in accordance with embodiments of theinvention.

FIG. 6 illustrates an example of a flowchart for the operation of aqueue callback manager application, in accordance with embodiments ofthe invention.

FIG. 7 illustrates one example of an equation to calculate estimatedwait time for predicting how long a caller will wait in a caller queuebefore speaking live with a properly skilled agent or resource, inaccordance with embodiments of the invention.

FIG. 8 illustrates a flowchart for improving the reconnection of acaller to a target agent resource when a callback is initiated, inaccordance with embodiments of the invention.

DETAILED DESCRIPTION

In the following detailed description, numerous specific details are setforth in order to provide a thorough understanding of the invention.However it will be understood by those of ordinary skill in the art thatthe invention may be practiced without these specific details. In otherinstances, well-known methods, procedures, components and circuits havenot been described in detail so as not to obscure the invention. Variousmodifications to the described embodiments will be apparent to thosewith skill in the art, and the general principles defined herein may beapplied to other embodiments. The invention is not intended to belimited to the particular embodiments shown and described.

FIG. 1 illustrates an overall architecture of a multi-tenant servicesintegration platform, in accordance with embodiments of the invention.The services integration platform 120 may operate with the use ofseveral servers 151, 152, 153, and 154. The services integrationplatform 120 may be accessed by users over a public switched telephonenetwork (PSTN) 100 through a PBX or other media device 110. The servicesintegration platform 120 may be provided as a hosted software service,and may include multi-tenant services 130 and data management services140. The services integration platform 120 may be an integrated solutionwhich provides such applications as customer interaction management,inbound and outbound dialing, real time and historical reporting thatprovides views of contact center performance 134, callback services 133,advanced voice platform with a routing system 132, IVR 131, and speechself service, call recording and quality monitoring, workforcemanagement, multi-channel e-services (voice, email, chat and fax),integration with leading CRM systems, custom integrations withmulti-vendor call processing and back office systems, end-to-endoperating, administration and provisioning environment 135, securitymaintained at the physical and data levels, and tools for maintainingSAS70 certification and HIPAA compliance.

The services integration platform 120 may deliver several multi-tenantsoftware as a service application 130. Thus, the applications may deployand support a shared tenant and shared services environment where therecan be many different customers (companies and users) running in theirown virtual partition from a single application instance. Theapplications may be multi-tenant aware and integrated into anadministration portal which integrates several shared tenant services.The tenant model may allow for customized application configurations tobe run from a single application instance. For example, a callbackapplication may use existing routing and reporting objects for calltracking that do not require the addition of specific and proprietaryconfiguration items. Instead, a customer (or tenant) can be segmentedinto a single virtual location to run from a single applicationinstance.

The services integration platform and/or one or more servers describedherein may include a programmable processor capable of executing one ormore step, such as those described herein. The services integrationplatform and/or one or more servers may include a memory capable ofstoring information, such as non-transitory computer readable media thatmay include code, logic and/or instructions for one or more steps.

Referring to FIG. 2, an example of how multi-tenancy can be accomplishedvia various abstraction layers is illustrated, in accordance withembodiments of the invention. As shown in FIG. 2, the user interface isimplemented and abstracted from the underlying infrastructure which mayallow the offering of multi-tenancy for offering various services acrossmultiple vendor applications which may be provided by many vendors. Asshown, the user interface is accessed through the application layer 201.Various services such as contact, administrative, case, pulse, scriptingand reporting services are offered from the application layer 201.Various vendor applications sit within the integration framework layer203, such as IVR, call recording, quality management, etc. Within thetransaction processing layer 202 are several drivers which areimplemented to allow for access to the various applications within theintegration framework layer 203. The various applications within thetransaction processing layer 203 may or may not support multi-tenancy,but multi-tenancy is achieved by the drivers at the transactionprocessing layer 202 and integrated into the user interface at theapplication layer 201. In this manner, applications from vendors whichare not multi-tenant can be utilized by multiple tenants via theabstraction, and the framework may enable rapid deployment, scalabilityand reconfiguration. Using this abstraction, a separation may bemaintained for the various customers or tenants. Thus, each applicationmay be private and organized or segregated for each tenant. In thismanner, the user interface is abstracted from the underlinginfrastructure, providing the flexibility to develop or license variousapplications which may or may not support multi-tenancy.

Referring to FIG. 3, the hierarchy of how configuration data for eachapplication within the application layer may be specified isillustrated, in accordance with embodiments of the invention. As shownin FIG. 3, configuration data may be provided for various applications,and allows for different configurations for different applications usingone instance of the installation of such application. For example,Config Data I may represent configuration data for two applications AppA and App B; Config Data II may represent configuration data for twoapplications App A and App B; and Config Data III may representconfiguration data for one application App C. Configuration data mayinclude customization preferences of certain tenants. For example,configuration data may include setup skills of agents who answer calls(e.g., a certain tenant has 100 agents who are skilled in business,another 100 agents who are skilled in claims processing, etc.). Theconfiguration data may allow various tenants the capability of groupingindividual agents into groupings of agents, designating certain groupsof agents to answer certain types of calls, may allow for groupings ofagents, or other configurations which implement a tenant's customizationpreferences. The configuration data may also be shared and moved betweenapplications. For example, Config Data I may be associated and used forApp A and App B, and Config Data II may also be associated with and usedfor App A and App B, where App A and App B are each installed only once.

The configuration data may also allow various views of the applicationsto be provided (or different customizations of the user interfaces of anapplication). More specifically, the configuration data may specify howthe views of an application are displayed, how data is output by theapplication, how the data is used by an application, etc. For example,Config Data I may provide for a certain view (such as the view that maybe applicable to IT administrators) of App A and App B. In such manner,a tenant may be allowed access into certain views or a certaincombination of views for specific applications. Each tenant's access tothe customized views, data, and input into specific applications iscompletely separated from other tenants; in this manner, each tenant mayoperate various applications within their own tenant-environment. Ratherthan requiring separate licenses from vendors, by utilizing instances ofvarious applications, it may be the case that only a single license isrequired from a vendor for a single installation of an application,rather than separate licenses for each tenant.

FIG. 4 illustrates how configuration data for each application may beimplemented by various tenants and among various agents, in accordancewith embodiments of the invention. As shown in FIG. 4, the configurationdata may be specific to particular tenants. For example, Tenant 1 mayhave Config Data I and Config Data III, meaning that Tenant 1 isassociated with and granted usage of the configuration data for Apps A,B and C. Tenant 1 may also employ various agents who only have access tocertain applications. This may be because certain agents are onlyskilled in certain areas or are better equipped to handle certain typesof calls or applications. Thus, in the example shown in FIG. 4, Agent 1has access to Apps A, B, and C for Tenant 1; Agent 6 has access to AppsA, B, and C for Tenant 1, but only Apps A and B for Tenant 3.

In this manner, configuration data (1) may allow differentconfigurations for different applications among one application install;(2) may provide for data moving between applications (e.g., onereporting/admin app governing other vendor's apps for data); (3) mayallow each application from different vendors to be set up with thecustomization preferences of each tenant where such setup isaccomplished with the services integration platform as a whole ratherthan for each application. Where some applications are multi-tenant andothers do not support multi-tenant functionality, by utilizingconfiguration data and the abstraction layers described above, theservices integration platform may accomplish multi-tenancy for allapplications offered through the platform. This architecture for themulti-tenancy management framework may provide the flexibility to crossassociate agent resources with more than one tenant and the ability toinclude or exclude applications for the users association by tenant.Applications can be customized to support an agent's user preferences,skill level, permissions, and other properties within a tenant so thatthe applications can be administered and provisioned with completeseparation from the other tenants. For example, Application A could be askills based application which the invention can associate and configurefor Agents 1 and 2 where both Agents 1 and 2 can set their own userpreferences within the application.

Thus, multiple levels of control and specificity may be provided in amulti-tenant system. In some embodiments, two or more levels, three ormore levels, four or more levels, five or more levels, or six or morelevels of control and/or specificity may be provided. Examples of levelsmay include specified configuration data and/or applications. Forexample, a tenant may select one or more configurations from a pluralityof available configuration options. In some instances, the availableconfiguration options may be provided system-wide across multipletenants, or may be provided only for individual tenants. A tenant maycreate a customized configuration. A configuration may include theselection of one or more applications from a plurality of availableapplication options and/or the creation of a customized application. Anapplication may include the selection of one or more agents from aplurality of available agents and/or the creation of a customized agentgroup. In some instances, one or more of the configuration data,applications, and/or agents may be supported across multiple tenants.The control and/or specificity may dictate which agents and/or groups ofagents may respond to a call and/or when or how the agents respond to acall. The control and/or specificity may also dictate the viewspresented to one or more user of a tenant's system, such as an agent oradministrator.

Referring to FIG. 5, an example of an architecture of a multi-tenantqueue callback manager application is illustrated, in accordance withembodiments of the invention. A queue callback manager application maybe one of many applications provided as part of the multi-tenantservices offered via a services integration platform. Utilizing a singleinstallation, multiple tenants may specify different configurations forthe queue callback manager application. When a caller calls a contactcenter seeking to be connected to an agent resource, the queue callbackmanager application may allow the caller to be quoted an expected waittime, and allow the caller to have the choice of a callback based on thesystem generated estimated wait time or to wait in a queue on hold. Asshown in FIG. 5, this application may support multiple tenants (i.e.,may support multiple entities, multiple business units within an entity,etc.).

As shown in FIG. 5, various callers 501, 502, 503, and 504 may placecalls to one or more contact centers. An IVR 510 and ACD 511 may attemptto route these calls to appropriate agent resources. The queue callbackmanager 512 may manage the initial contact and re-contact of callers inan efficient and cost effective manner, without having to set up aseparate system for each tenant. As shown, various queue instances maybe created for various tenants. For example, queues 521 and 522 may becreated for Tenant 001; queue 523 may be created for Tenant 028; queue524 may be created for Tenant 105; and queue 525 may be created forTenant NNN. Whereas without multi-tenancy, there is a need to set upeach queue with a separate system, multi-tenancy allows each queue to beinstances and to be replicated. Whereas other systems may eliminate theneed to set up each queue within a separate system by running variousvirtual machine containers, this method presents issues with sharingother multi-tenant services.

Utilizing the architecture presented in FIG. 5, the queue callbackmanager application 512 may have various caller queue instances, andshare call management services 513 and viewer reporting services 514,and other multi-tenant services. Thus, a multi-tenant system and methodcan be enabled for offering contact back requests for incoming callersacross different tenants, providing each caller an estimated wait timebased on their environment instance, allowing the caller to disconnectwhile maintaining their position in their contact center queue instance,and initiating re-contact to the caller to the appropriate resource intheir tenant instance when their turn is due. Each tenant may be acompany, a division within a company, or a business unit within adivision, for example. There may also be a hierarchy of tenants, suchthat one tenant is a master tenant and other tenants are sub-tenants.

Although multiple queue instances are maintained, the system may consistof a single instance management system that partitions and administersthe caller queue instances to provide separation between the callerqueues. Within each queue instance, the management services 513 can keeptrack of where the callers are within the queue, and each queue may bepartitioned such that separation is maintained. Multi-tenancy may beachieved through the management framework providing data isolationservices that associate users and user organizations with tenants,associates relevant application configurations with tenants, users withapplications, and applications with tenants.

Thus, the system may include multi-tenant administration services thatare used for administering each and every agent queue instance so thespecific queues can be monitored, adjusted, or flushed in real timewithout any effect on the other agent queues. The system may alsoinclude multi-tenant reporting services 514. The reporting services 514may provide various statistics, such as how tenants are charged, etc.,and may have real-time views of every caller waiting in a queueinstances. The real-time views may display which callers are eitherphysically holding on line or which callers have elected to be contactedback and are holding their place in line, for example. Othermulti-tenant services may also be offered such as call processingservices, administration services, provisioning services, reportingservices, integration services, or data isolation services. For example,administration services may designate which agents serve which callerqueues; provisioning services may provide for a way to set up andimplement queues for tenants; and data isolation services and databasesmay keep track of where every caller is within the queue instance.

Referring to FIG. 6, a flowchart for the operation of a queue callbackmanager application is provided, in accordance with embodiments of theinvention. Since callers generally do not like being placed on hold andexperiencing long wait times when trying to access agent resources, thequeue callback manager application may give callers a choice to wait onhold or to receive a call back at a promised time from a skilled agentthat is able to support the caller. In step 601, an incoming callerestablishes communication through a network 602. In step 603, a PBX ormedia device receives the call, in step 604, the call is handled by aSIP server. In step 605, an IVR system may provide an automaticpre-recorded response. In step 606, a statistics collection server maycollect and store certain information. In step 607, a routing enginewill handle the call. In step 608, the caller may be placed in aninitial queue. In step 609, the caller's estimated wait time may becalculated. If an agent resource is immediately available in step 610,then the caller may be connected to the resource in step 611. If anagent resource is not immediately available to assist the caller in step610, and if the estimated wait time is less than a certain threshold ofX seconds in step 612, then the caller will be placed on hold in step613 and connected to a caller resource in step 611 when one becomesavailable.

If an agent resource is not immediately available to assist the callerin step 610, and if the estimated wait time is greater than a certainthreshold of X seconds in step 612, then the caller will be asked ifthey prefer a call back in step 614. If the caller does not choose toreceive a callback in step 615, then the caller will remain on hold instep 616 and remain in the caller queue instance for the specifiedtenant. If the caller chooses to receive a callback in step 615, thenthe caller will be provided an estimated wait time for the callback instep 617, the caller will be tagged or ticketed for a callback in step618 and will remain in the caller queue instance for the specifiedtenant. In step 619, if the callback requirements (e.g., if the callerprovided a callback number) are true, then in step 620, the resources,queue and external parameters are evaluated (as further describedbelow). In step 621, the callback process is initiated and in step 622,the caller is connected to the next available resource (customer serviceagent).

Additional enhancement for the customer experience and enhancements forsystem optimization may also be implemented. For example, if a caller isreluctant to accept a callback offer, then the caller may choose toremain on hold and remain in the caller queue. While on hold, the callermay then opt to get a callback by actively making a selection (such aspressing the * key). In some instances, while on hold, the caller may bepresented with an updated estimated wait time. Another option orenhancement may be to offer a callback for a caller at a specific time(instead of providing an estimated callback time). Additionally, if acaller does not answer the callback, the caller may be left an option ormay be sent a message (such as a text message) which allows the callerto place another call to the call contact center with high priority.There may also be an option for a caller who has elected to receive acallback to, at any point, call back to the call contact center and optback into the on-hold queue with a higher priority.

Other databases and subsystems may be accessed to gather additionalinformation for each tenant to optimize call decision making Forexample, various variables relating to the resources available to atenant may be taken into account, such as the forecast and schedule ofagent resources, vacation of agent resources, efficiency of agentresources, etc. Schedule information may be analyzed to determine agentcapacity before a callback is made, which may provide for more efficientutilization of agent resources.

FIG. 7 illustrates one example of an equation to calculate estimatedwait time for predicting how long a caller will wait in a caller queuebefore speaking live with a properly skilled agent or resource, inaccordance with embodiments of the invention. The estimated wait timecalculation takes into account: (1) how many other callers are in queue;(2) the total number of agents available; (3) the total number of agentswith the target skill set; (4) the speed at which the agents with thetarget skill set are answering callers within a current sampling window;(5) the volatility of recent average speed answer by the target agentskill group; and (6) the currency of all sampled information used topredict EWT. The calculation may rely on certain historical informationto take a sample (for example, the current sampling window may be 15seconds). Further, the volatility of recent average speed answer by thetarget agent skill group may be normalized.

As shown in FIG. 7, if the average speed of answer computed by skilledagents for the last N seconds for the relevant queue is greater than 0,then this means that during the sampling window, there was at least onecall answered and the estimated wait time will be calculated as the sumof the average speed of answer plus the number of calls currently in thequeue for the specific skill group. For example, if N=20 seconds and theaverage speed of answer computed by skilled agents for the last 20seconds in the relevant queue was 40 seconds, and there are 10 callswaiting in queue, then the estimated wait time will be 50 seconds. Thispart of the calculation is designed to calculate EWT accurately forlarger agent pools of greater than 10 agents and large caller poolswhere the arrival rate of callers can provide at least 2 samples withinthe sampling window of N seconds for the target agent pools.

If, however, the average speed of answer computed by the skilled agentfor the last N seconds for the relevant queue is not greater than 0,then the estimated wait time will be calculated based on various otherhistorical factors such as the agent ratio and queue ratio as shown inFIG. 7. For the purposes of this calculation, agents are only consideredready if they have been in the ready state for more than 5 seconds or atsome other preset time parameter. The alternative calculation is usefulfor calculating EWT accurately for small queues that are being handledby a few agents where the incoming call traffic volume is sporadic. Forexample, if the average speed of answer across all target queues is 40seconds and there are 50 callers waiting in queue where the calculatedAgent Ratio is 3.0 and the calculated Queue Ratio is 3.5 where there are10 agents ready at that time to help callers, then the estimated waittime will be 95 seconds.

The punctuality of the estimated wait time algorithm and an alternativesystem for calculating estimated wait time was tested against manyvariations of large and small queues real sample data. Test resultsshowed that the punctuality of the estimated waited time algorithm wasconsistently higher than 90% accurate within a 2 minute deviation rangewhen compared with the actual wait time experienced by callers. Thealternative system for calculating estimated wait time was also testedfor comparison where its calculations are primarily driven by averagehold time, number of skilled agents available, and number of callers inqueue. Test results showed that the punctuality for the alternativealgorithm averaged from 70% to 80% accurate within a 2 minute deviationrange when compared with the actual wait time experienced by callers.Based on these test results the estimated wait time algorithm wassignificantly more accurate than the alternative system.

FIG. 8 illustrates a flowchart for improving the reconnection of acaller to a target agent resource when a callback is initiated, inaccordance with embodiments of the invention. When a callback isinitiated, the system will use the flowchart illustrated in FIG. 8 todetermine when to callback a caller for the fastest reconnection to thetarget agent resource without disruption and within the time frameclosest to the promised estimated wait time. This process of callbackinitiation takes into account: (1) estimated wait time promised; (2)number of actual calls in queue with skilled agent (situationalchanges); (3) callbacks in queue can be serviced by the current level ofavailable staffing; (4) longest caller queue time is less than N seconds(setting to a desired service level threshold) (e.g., a company mayrequire this “N” to be 30 seconds); (5) callback event has to havewaited in queue longer than P seconds (e.g., if the estimated wait timepromised is 5 minutes, but an agent resource immediately becomesavailable, the P seconds may be set to 2 minutes to avoid having thesystem provide the caller with an immediate callback which may be anuisance); and (6) automatic throttle to prevent too many high prioritycalls from being introduced to the same queue.

As illustrated in FIG. 8, when a caller's turn is approaching, variousparameters or variables may be checked before the callback is initiated,to ensure a very high level of success for the caller to be connected toan agent resource as quickly as possible. The caller is first placed ina callback queue in step 801 and may elect to receive a callback in step802. In step 803, the system may evaluate several triggers (804) beforethe callback initiation to make sure all necessary customer resourcesneeded to service the customer will be available when that caller isreconnected. Triggers (804) may include if there are 0 calls in allqueues with skilled agents ready (805), if the caller is reaching 80% oftheir quoted estimated wait time (806), and if the current estimatedwait time for similar calls is less than n % of the original estimatedwait time quote (807). If any of these triggers are true, then thesystem may check to see whether a certain minimum try back time hasexpired yet or not (808). When this minimum try back time expires, thenseveral factors are considered including whether a ratio of callbacks tonumber of staff is less than 10% (810), whether the longest caller inthe queue is less than 30 seconds (811), whether the callback has beenin the queue longer than X seconds (812), and whether there are too manycalls in the queue at a high priority (814). If these throttle factorsare false, then additional time may be added to the minimum try backtime (813). If the throttle factors are true, then the callback may beprocessed (815).

In the event that the reconnect or callback is failed (for example, ifthe caller does not pick up), then there may be a certain time withinwhich the process is re-started and another callback may be attempted.If the caller declines the reconnect or callback, then the denial may berecorded accordingly. Utilizing this flowchart and taking into accountthe various trigger and throttle factors may allow the system tore-connect the caller as fast as possible to ensure that the caller cantalk to the customer service rep in the shortest amount of time.

Aspects of the systems and methods described may be implemented asfunctionality to provide multi-tenant services for use with mobileapplications and/or web applications. Systems and methods providedtherein may be accessible by and/or implemented using mobile devices(e.g., smartphone, PDA, cellular phone, tablet) and/or static devices(e.g., personal computer, workstation). In one example, systems andmethods may be capable of providing mobile device users and/or web userswith any functionality described herein, which may include specificationof configurations for one or more tenants, estimated wait times and callback capabilities.

The underlying systems and methods can provide these services using textcommunication channels including chat and short message services inaddition to voice channels. Any description herein relating to calls orcallers may also apply to chat services (e.g., via text, audio, and/orvideo), email services, message services (e.g., text message), or anyother forms of communication. Any form of communication may be initiatedby a caller, and any description of a caller may apply to an individualthat initiates any form of communication, such as a telephone phone orany other forms described therein. Similarly, any form of communication(e.g., telephone call or other forms described herein) may be used torespond to the caller. The response may include a callback to thecaller, a connection that is made between the caller and call centeragent, and/or an indication to the caller of the expected wait time fora callback (at the onset of the caller's initiated communication orupdates provided subsequently). Any description of a callback mayinclude any form of communication. The response may take the same formas the communication initiated by the caller (e.g., if the caller callsvia telephone, the caller receives a telephone call back) or may take adifferent form as the communication initiated by the caller (e.g., ifthe caller calls via telephone, the caller hears an expected callbacktime, selects a callback option, and receives a text updating thecallback time).

For further examples, an individual may “call in” to a service byinitiating a communication, such as contact via a chat session (e.g.,via text, audio, and/or video) of a web site, or a chat via a mobiledevice. In some embodiments, one or more agents may be available torespond to the communication (e.g., enter a chat session, or text oremail back). The one or more agents may respond in accordance with thedata configuration for the tenant that the individuals are communicatingwith, and/or in accordance with the appropriate call center application.In some instances, when the communication request is made, anappropriate agent may not be available at the time. For example, thecommunication request may specify a need of the caller that can be metby an agent with an appropriate skillset. An expected wait time for anappropriate agent to become available may be calculated. The calculationmay occur in accordance with one or more calculation described herein,or other calculations known in the art. The expected wait time may bepresented to the caller, using one or more of the communicationtechniques described herein. The caller may be presented with an optionof remaining on hold or receiving a callback. The caller's selection maybe received and one or more steps may be initiated in response.

In some embodiments, the callers may be utilizing an application on amobile device to initiate a communication, and/or receive a response tothe communication. The caller may automatically receive a response tothe communication via the same device. Alternatively, the caller mayspecify a different device through which to receive the communication.In some instances, an agent may interface with the caller via a mobiledevice of the agent. Alternatively, one or more of the devices utilizedby the caller and/or agent need not be a mobile device.

Similarly, a user of the systems and methods described herein, such asan administrator for a tenant may utilize an application on a mobiledevice, or any other type of device. For example, an administrator mayspecify and/or adjust configuration data and/or applications through aninterface provided on a mobile device or other type of device. In otherexamples, a system-wide administrator that may be capable of interactingwith one or multiple tenants may interact with the system via a mobiledevice or any other type of device.

All concepts of the invention may be incorporated or integrated withother systems and methods of multi-tenant call center systems, includingbut not limited to those described in U.S. Patent Publication No.2005/0025303 (Hostetler) published on Feb. 3, 2005 and U.S. Pat. No.6,788,779 (Ostapchuck) issued on Sep. 7, 2004, which are herebyincorporated by reference in their entirety.

While preferred embodiments of the present invention have been shown anddescribed herein, it will be obvious to those skilled in the art thatsuch embodiments are provided by way of example only. Numerousvariations, changes, and substitutions will now occur to those skilledin the art without departing from the invention. It should be understoodthat various alternatives to the embodiments of the invention describedherein may be employed in practicing the invention. It is intended thatthe following claims define the scope of the invention and that methodsand structures within the scope of these claims and their equivalents becovered thereby.

While this invention has been described and illustrated with referenceto particular embodiments, it will be readily apparent to those skilledin the art that the scope of the invention is not limited to thedisclosed embodiments but, on the contrary, is intended to covernumerous other modifications and equivalent arrangements which areincluded within the spirit and scope of the following claims.

Aspects of the systems and methods described herein may be implementedas functionality programmed into any of a variety of circuitry,including programmable logic devices (PLDs), such as field programmablegate arrays (FPGAs), programmable array logic (PAL) devices,electrically programmable logic and memory devices and standardcell-based devices, as well as application specific integrated circuits(ASICs). Some other possibilities for implementing aspects of thesystems and methods include: microcontrollers with memory, embeddedmicroprocessors, firmware, software, etc. Furthermore, aspects of thesystems and methods may be embodied in microprocessors havingsoftware-based circuit emulation, discrete logic (sequential andcombinatorial), custom devices, fuzzy (neural network) logic, quantumdevices, and hybrids of any of the above device types. Of course theunderlying device technologies may be provided in a variety of componenttypes, e.g., metal-oxide semiconductor field-effect transistor (MOSFET)technologies like complementary metal-oxide semiconductor (CMOS),bipolar technologies like emitter-coupled logic (ECL), polymertechnologies (e.g., silicon-conjugated polymer and metal-conjugatedpolymer-metal structures), mixed analog and digital, etc.

It should be noted that the various functions or processes disclosedherein may be described as data and/or instructions embodied in variouscomputer-readable media, in terms of their behavioral, registertransfer, logic component, transistor, layout geometries, and/or othercharacteristics. Any description of computer-readable media may includenon-transitory and/or tangible computer readable-media.Computer-readable media in which such formatted data and/or instructionsmay be embodied include, but are not limited to, non-volatile storagemedia in various forms (e.g., optical, magnetic or semiconductor storagemedia) and carrier waves that may be used to transfer such formatteddata and/or instructions through wireless, optical, or wired signalingmedia or any combination thereof. Examples of transfers of suchformatted data and/or instructions by carrier waves include, but are notlimited to, transfers (uploads, downloads, email, etc.) over theInternet and/or other computer networks via one or more data transferprotocols (e.g., HTTP, FTP, SMTP, etc.). When received within a computersystem via one or more computer-readable media, such data and/orinstruction-based expressions of components and/or processes under thesystems and methods may be processed by a processing entity (e.g., oneor more processors) within the computer system in conjunction withexecution of one or more other computer programs.

Unless specifically stated otherwise, as apparent from the followingdiscussions, it is appreciated that throughout the specification,discussions utilizing terms such as “processing,” “computing,”“calculating,” “determining,” or the like, may refer in whole or in partto the action and/or processes of a processor, computer or computingsystem, or similar electronic computing device, that manipulate and/ortransform data represented as physical, such as electronic, quantitieswithin the system's registers and/or memories into other data similarlyrepresented as physical quantities within the system's memories,registers or other such information storage, transmission or displaydevices. It will also be appreciated by persons skilled in the art thatthe term “users” referred to herein can be individuals as well ascorporations and other legal entities. Furthermore, the processespresented herein are not inherently related to any particular computer,processing device, article or other apparatus. An example of a structurefor a variety of these systems will appear from the description below.In addition, embodiments of the invention are not described withreference to any particular processor, programming language, machinecode, etc. It will be appreciated that a variety of programminglanguages, machine codes, etc. may be used to implement the teachings ofthe invention as described herein.

Unless the context clearly requires otherwise, throughout thedescription and the claims, the words ‘comprise,’ ‘comprising,’ and thelike are to be construed in an inclusive sense as opposed to anexclusive or exhaustive sense; that is to say, in a sense of ‘including,but not limited to.’ Words using the singular or plural number alsoinclude the plural or singular number respectively. Additionally, thewords ‘herein,’ ‘hereunder,’ ‘above,’ ‘below,’ and words of similarimport refer to this application as a whole and not to any particularportions of this application. When the word ‘or’ is used in reference toa list of two or more items, that word covers all of the followinginterpretations of the word: any of the items in the list, all of theitems in the list and any combination of the items in the list.

The above description of illustrated embodiments of the systems andmethods is not intended to be exhaustive or to limit the systems andmethods to the precise form disclosed. While specific embodiments of,and examples for, the systems and methods are described herein forillustrative purposes, various equivalent modifications are possiblewithin the scope of the systems and methods, as those skilled in therelevant art will recognize. The teachings of the systems and methodsprovided herein can be applied to other processing systems and methods,not only for the systems and methods described above.

The elements and acts of the various embodiments described above can becombined to provide further embodiments. These and other changes can bemade to the systems and methods in light of the above detaileddescription.

In general, in the following claims, the terms used should not beconstrued to limit the systems and methods to the specific embodimentsdisclosed in the specification and the claims, but should be construedto include all processing systems that operate under the claims.Accordingly, the systems and methods are not limited by the disclosure,but instead the scope of the systems and methods is to be determinedentirely by the claims.

While certain aspects of the systems and methods are presented below incertain claim forms, the inventor contemplates the various aspects ofthe systems and methods in any number of claim forms. Accordingly, theinventor reserves the right to add additional claims after filing theapplication to pursue such additional claim forms for other aspects ofthe systems and methods.

1-20. (canceled)
 21. A system for managing multi-tenant callbackservices for customer contact centers comprising: a processor; a memory,wherein the memory has stored therein instructions that, when executedby the processor, cause the processor to: receive configuration data foreach of a plurality of customer contact center tenants; receive requestsfrom the plurality of customers, wherein each of the requests is arequest to be connected to an agent resource of a tenant of theplurality of the tenants; identify, for callback, a first customer ofthe plurality of customers transmitting a first one of the requests fora first tenant of the plurality of tenants; identify, for callback, asecond customer of the plurality of customers transmitting a second oneof the requests for a second tenant; manage callbacks for the first andsecond tenants according to the corresponding configuration data;monitor, via a single instance of an application, position of the firstcustomer in a first queue instance associated with the first tenant andposition of the second customer in a second queue instance associatedwith a second tenant, the first and second queue instances each runningin a virtual partition provided for respectively the first and secondtenants; and invoke a callback to the first customer in response to themonitoring of the position of the first customer in the first queueinstance; and a media device coupled to the processor adapted toestablish a connection with a communication device of the first customerin response to the invoked callback.
 22. The system of claim 21, whereinthe configuration data for the first tenant includes skill sets for theagent resources of the first tenant.
 23. The system of claim 21, whereinthe instructions further cause the processor to: calculate an expectedwait time for the first customer.
 24. The system of claim 23, wherein afirst formula is used to calculate the expected wait time if at leastone call was answered during a particular sampling window, and a secondformula different from the first formula is used to calculate theexpected wait time if no call was answered during the particularsampling window.
 25. The system of claim 24, wherein the first formulais configured to compute the expected wait time as a sum of an averagespeed of answer during the particular sampling window plus a number ofcalls currently in the first queue instance for a specific skill group.26. The system of claim 24, wherein the second formula is configured tocompute the expected wait time based on an average speed of answercomputed across a plurality of queues during the particular samplingwindow.
 27. The system of claim 21, wherein the instructions furthercause the processor to: invoke the single instance of the applicationfor adjusting the first queue instance in real time without affectingthe second queue instance.
 28. The system of claim 21, wherein thevirtual partitions are configured to provide separation between thefirst and second queue instances.
 29. A method for managing multi-tenantcallback services for customer contact centers comprising: receiving, bya processor, configuration data for each of a plurality of customercontact center tenants; receiving, by the processor, requests from theplurality of customers, wherein each of the requests is a request to beconnected to an agent resource of a tenant of the plurality of thetenants; identifying for callback, by the processor, a first customer ofthe plurality of customers transmitting a first one of the requests fora first tenant of the plurality of tenants; identifying for callback, bythe processor, a second customer of the plurality of customerstransmitting a second one of the requests for a second tenant of theplurality of tenants; managing, by the processor, callbacks for thefirst and second tenants according to the corresponding configurationdata; monitoring, by the processor, via a single instance of anapplication, position of the first customer in a first queue instanceassociated with the first tenant and position of the second customer ina second queue instance associated with a second tenant, the first andsecond queue instances each running in a virtual partition provided forrespectively the first and second tenants; invoking, by the processor, acallback to the first customer in response to the monitoring of theposition of the first customer in the first queue instance; andestablishing, by a media device, connection with a communication deviceof the first customer in response to the invoked callback.
 30. Themethod of claim 29, wherein the configuration data for the first tenantincludes skill sets for the agent resources of the first tenant.
 31. Themethod of claim 29 further comprising: calculating, by the processor, anexpected wait time for the first customer.
 32. The method of claim 31,wherein a first formula is used to calculate the expected wait time ifat least one call was answered during a particular sampling window, anda second formula different from the first formula is used to calculatethe expected wait time if no call was answered during the particularsampling window.
 33. The method of claim 32, wherein the first formulais configured to compute the expected wait time as a sum of an averagespeed of answer during the particular sampling window plus a number ofcalls currently in the first queue instance for a specific skill group.34. The method of claim 32, wherein the second formula is configured tocompute the expected wait time based on an average speed of answercomputed across a plurality of queues during the particular samplingwindow.
 35. The method of claim 29, wherein the method further includes:invoking, by the processor, the single instance of the application foradjusting the first queue instance in real time without affecting thesecond queue instance.
 36. The method of claim 29, wherein the virtualpartitions are configured to provide separation between the first andsecond queue instances.